I just pushed a commit switching from Alpine to Debian as the base of the Docker image.

When using Alpine, the image worked for simple --help output, but when I tried to connect to any relay, I got the following (with RUST_LOG set to debug):

[2023-04-29T22:21:10Z INFO  nostcat] Spawning thread for -- wss://nostr.bitcoiner.social/
[2023-04-29T22:21:10Z DEBUG tungstenite::client] Trying to contact wss://nostr.bitcoiner.social/ at 23.146.144.108:443...

The program died immediately after those two lines with exit code 139 (segfault).

I'm not super familiar with Rust, so if you have any idea what would cause those segfaults I can change it back (and save a few hundred MB), but for now I'll just use the Debian base image since that doesn't crash.

Oh good idea, building in Debian and running in Alpine might work.

I tried that briefly, but I'm having some trouble hooking up the dynamically-linked libraries at present; I'll troubleshoot a bit more and see if I can make that work.

If you want to merge this PR, I can open a new one if/when I get it working. Otherwise I'll just push another commit to this one.

@501st-alpha1 I've spent some time to get a compact and functional Docker image, and I think I have something that's decent. It's only 30mb. If you're able to give it a go (instructions at bottom on README.md and let me know how it goes.

RE: #6 If you can also try testing it using torify. I was unable to find a nostr tor relay that was functional, so if you'd like me to test, can you share the tor onion url?

Connecting to tor onion relays

$ echo '["REQ", "RAND", {"kinds": [1], "limit": 2}]' | torify nostcat wss://TOR_URL.onion

In testing, I found the dependencies seemed to use a mix of dynamic and static openssl support - which was likely the cause of the segfault.

If you're able to give it a go (instructions at bottom on README.md) and let me know how it goes.

I tested it and it works great, thanks! I'll close this PR.

RE: #6 If you can also try testing it using torify. I was unable to find a nostr tor relay that was functional, so if you'd like me to test, can you share the tor onion url?

Yes, my workaround to connect to onion relays from the Docker image still works: I did apk add torsocks in the Alpine image, then ran it like this:

echo '["REQ", "some value", {"ids": ["0ddafa397165c9c9f845378d890a99cb51466fab9e81035cd9dabdcd1e3bf6a3"]}]' | docker run -i --rm --net=host --entrypoint torsocks nostcat nostcat ws://rvqkqr5kl3dvvxyn67rfowcnvoflx4zby5tjbysavym4ycckti4dbjyd.onion/

You should have read-only access to the onion listed there. To explain some of the other args (just in case):

• --net=host: use host network for Docker container so I can connect to the Tor service running on my host, rather than installing it again in the container.
• --entrypoint torsocks: override the entrypoint to "torify" nostcat.
• nostcat nostcat: doubled because first argument is image name, second is the argument passed to torsocks telling it to run nostcat.
• ws://: onion connections are already encrypted, so adding TLS via. wss is redundant.

Thanks again!

@blakejakopovic If this is the only tor solution, why was this not merged?

@dskvr See this comment; a Dockerfile was added to this repo separately, making this PR obsolete. (Neither Dockerfile includes Tor by default; I just extended it to add torsocks to the image so I could hack together a solution as described above.)